1. Field of the Invention
The field of the invention is data processing, or, more specifically, methods, systems, and products for generating test programs for J2EE Java Enterprise web applications.
2. Description of Related Art
Enterprise Web Applications are increasingly complex, mission critical, and important revenue generators for many corporations in many different industries. Testing such applications to verify their correctness, reliability, availability, and security is an important part of the overall engineering effort required to produce and deploy them. Developing these test or verification programs is typically a manual, labor intensive software development effort in itself. These tests must be maintained along with the Enterprise Web Application such that if an enhancement or modification is made to the Web Application, the tests are also modified and executed to test the enhancement or modification.
Java 2 Enterprise Edition (J2EE) is a set of technologies and specifications developed by Sun Microsystems and supported by many computer and software vendors, including for example, IBM, BEA, and Oracle) as a leading platform for developing and deploying enterprise web applications. The J2EE specifications specify a declarative programming model where many attributes (transaction requirements and semantics, security constraints and roles, lifecycle characteristics, persistence mechanisms, and other quality of service attributes of the Enterprise Application are captured in ascii XML files call ed deployment descriptors (DDs). DDs are used by the J2EE runtime execution environment to provide and enforce the quality of service attributes described in the DD.
A J2EE application consists of one or more J2EE modules and one J2EE application deployment descriptor. An application deployment descriptor contains a list of the application""s modules and information on how to customize the application. A J2EE application is packaged as a Java Archive (JAR) file with an ear (Enterprise archive) extension. A J2EE module consists of one or more J2EE components for the same container type and one component deployment descriptor of that type. A component deployment descriptor contains declarative data to customize the components in the module. A J2EE module without an application deployment descriptor can be deployed as a stand-alone J2EE module.
The three types of J2EE modules are:
Enterprise JavaBeans modules contain class files for enterprise beans and an EJB deployment descriptor. EJB modules are packaged as JAR files with a jar extension.
Web modules contain JSP files, class files for servlets, GIF and HTML files, and a Web deployment descriptor. Web modules are packaged as JAR files with a war (Web archive) extension.
Application client modules contain class files and an application client deployment descriptor. Application client modules are packaged as JAR files with a jar extension.
Central to the J2EE component-based development model is the notion of containers. Containers are standardized runtime environments that provide specific component services. In addition, containers provide a mechanism for selecting application behaviors at assembly or deployment time. Through the use of deployment descriptors (text files that specify component behavior in terms of well-defined XML tags), components can be configured to a specific container""s environment when deployed, rather than in component code. Features that can be configured at deployment time include security checks, transaction control, and other management responsibilities.
A few background definitions: xe2x80x9cQuality-of-servicexe2x80x9d or xe2x80x9cQOSxe2x80x9d refers to the application behaviors or XML tags related to the security or transaction control aspects of an enterprise application. xe2x80x9cDDxe2x80x9d is an acronym for deployment descriptor. An XML parser is a software tool capable of reading an XML document and breaking down XML elements into usable parts. There are many Java XML parsers available, including, for example, the Apache Software Foundations Xerces, Oracle""s XML Parser, and IBM""s XML4J.
xe2x80x9cApplication.xmlxe2x80x9d is a filename used to denote an application deployment descriptor file for an J2EE application. xe2x80x9cWeb.xmlxe2x80x9d is a filename typically used to denote a deployment descriptor file for a Web module in a J2EE application. xe2x80x9cEjb-jar.xmlxe2x80x9d is a filename typically used to denote a deployment descriptor file for an EJB module in a J2EE application.
xe2x80x9cURIxe2x80x9d or xe2x80x9cURLxe2x80x9d refers to Uniform Resource Identifier or Uniform Resource Locator, the standard method of locating and identifying distributed resources on the World Wide Web.
A xe2x80x9crolexe2x80x9d or xe2x80x9csecurity rolexe2x80x9d is a classification of the type of identity required to access a protected resource. Roles specified in deployment descriptors are typically associated with EJB methods and WEB URIs. When a J2EE application is deployed or installed, an administrator maps actual users and/or groups to the roles. The security code in either the web or EJB container inspects the role that the requesting user is in, and, if it matches any of the roles associated with a URI or EJB method, then the user is in the role and access is permitted.
For more background information regarding J2EE, readers are referred to the Sun Systems"" publication, Designing Enterprise Applications with the Java 2 Platform, Enterprise Edition, by Nicholas Kassem, ISBN 0-20-1702770.
Within the J2EE environment and system itself, there is no systemic structure or method for generating test code for J2EE applications. In the current state of the J2EE art, Java test code for J2EE applications is developed by hand. It would be advantageous for several reasons, however, to have the ability to automatically generate test programs because the generation of test programs is more efficient, potentially more accurate, potentially more complete, and less labor intensive than manually developing test programs. Generated test programs would have the advantage of covering or verifying more combination of actions, web application configurations or scenarios than can be practically developed otherwise. Automatic generation of tests programs would have the advantage of easing the maintenance burden of the web application over time.
Exemplary embodiments of the invention typically include a method of testing a J2EE application, wherein the J2EE application comprises modules. Exemplary embodiments typically include identifying, from an application deployment descriptor, modules comprised within the J2EE application, identifying, from an identified module, at least one QOS element, and identifying, from the identified QOS element, a software resource to be tested. Other exemplary embodiments typically include generating Java test code, identifying, for the software resource to be tested, a user identification and a user password for a user that is a member of a role intended to protect the software resource, and testing the software resource to be tested by use of the Java test code, including passing as parameters to the Java test code at run time the user identification and user password.
Exemplary embodiments of the invention typically include at least one of the identified modules having a web module having a web module deployment descriptor, and at least one of the identified QOS elements having a security-constraint element. Exemplary embodiments typically include identifying a software resource to be tested, constructing, from a  less than web-uri greater than  element in the application deployment descriptor and from a  less than url-pattern greater than  element in the web module deployment descriptor, a URI that identifies a software resource to be tested, and testing the software resource by use of the Java test code. In exemplary embodiments, testing the software resource typically includes passing as a parameter to the Java test code at run time the URI, invoking the URI wherein the invoking includes transmitting an HTTP request, wherein the HTTP request includes the URI, the user identification, and the user password, receiving an HTTP response, and determining in dependence upon the HTTP response whether the software resource is protected.
Exemplary embodiments of the invention typically include at least one of the identified modules having an Enterprise JavaBean module (xe2x80x9cEJB modulexe2x80x9d) with a deployment descriptor, and at least one of the identified QOS elements having a  less than method-permission greater than  restraint element. In exemplary embodiments, the  less than method-permission greater than  restraint element typically includes a first  less than method-name greater than  sub-element having a first  less than method-name greater than  sub-element value, and a first  less than ejb-name greater than  sub-element having a first  less than ejb-name greater than  sub-element value. Exemplary embodiments typically include the identified software resource to be tested having a JavaBean method. In typical embodiments, the JavaBean method includes identifying a software resource to be tested and finding in a deployment descriptor for the identified EJB module one or more  less than enterprise-bean greater than  elements having nested  less than ejb-name greater than  sub-elements having values equal to the first  less than ejb-name greater than  sub-element value.
In typical embodiments, each found  less than enterprise-bean greater than  element includes the nested  less than ejb-name greater than  sub-element, a  less than home greater than  nested sub-element, a  less than remote greater than  nested sub-element, and an  less than ejb-class greater than  nested sub-element. Other exemplary embodiments typically include identifying, for each found  less than enterprise-bean greater than  element, by use of Java reflection and the value of the  less than ejb-class greater than  element, a method signature having a method name equal to the first  less than method-name greater than  sub-element value; and testing the software resource by use of the Java test code. In typical embodiments, testing the software resource includes passing as a parameter to the Java test code at run time the JNDI name for the JavaBean method, logging in to an application environment by use of the user identification and the user password, and looking up the JavaBean home by use of a JNDI home name for the software resource. In typical embodiment, testing the software resource also includes creating, by use of the JavaBean home, an instance of the JavaBean, invoking, in the created instance, the protected JavaBean method, and reporting whether invoking the protected JavaBean method succeeded.
The foregoing and other objects, features and advantages of the invention will be apparent from the following more particular descriptions of exemplary embodiments of the invention as illustrated in the accompanying drawings wherein like reference numbers generally represent like parts of exemplary embodiments of the invention.